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(57) Abstract: The invention is a method for a multiple smart card simulator 
The invention allows cards with different characteristics such as memory, com- 
mand sequence, error handling, and data flow to be simultaneously simulated. It 

also permits simultaneous simulation of different smart card user applications. 
The method involves determining the characteristics of smart cards, and then 
modifying input and output to or from these cards based on the smart card char- 
acteristics. In this way, an end-to-end simulation environment is provided. 
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Title: METHOD FOR A MULTIPLE SMART CARD SIMULATOR 

This application claims priority from U.S. provisional application 60/138,679 filed June 14, 1999. 
Field of Invention 

The present application relates to a method for a multiple smart card simulator, and in particular, an 
application employing multiple simulated smart-cards where the applications running on, or enabled 
on, some of the smart cards differ from those applications running on, or enabled oh, other of the 
simulated smart cards, and where the smart cards may have different characteristics. 

Background to Invention 

Smart cards are hardware devices that typically have the shape and size of a credit card. Often they 
have an embedded computer processor, memory and an operating system. Often smart cards have 
stored in their memory information related to the user of the smart card. Such information can 
include: 

(i) personal information, such as name, address, other contact information, date of birth, 
etc.; 
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(ii) financial information, such as bank accoimt numbers and type of account, account 
balances and transaction histories, retirement savings plan information, investment 
information and investment portfolio and account information; 

(iii) medical information, such as medical history and known allergies and prescription 
history; 

(iv) information related to retail shopping, such as clothing sizes, shopping histories and 
product, preferences; and 

(v) other information relating to taste, style and economic, social or cultural activity. 

Smart cards are inserted into card terminals which may include automated teller machines, internet 
kiosks, pay telephones, point of sale terminals, cellular phones, or any device containing a card 
reader. 

Using the information stored on the smart card, the card terminals provide a variety of services and 
computer-based applications to the user of the smart card. These services can include: 

(i) paying bills, transferring money between accoimts, making investments, analyzing 
a portfolio; 
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(ii) ordering prescription drugs, providing information to health care professionals or 
receiving information from them; 

(iii) buying or selling consumer goods, receiving product information, participating in 
consumer surveys, receiving promotional offers, customizing products; and 

(iv) playing games or receiving other content such as music, video, text or unages. 

Different users of smart cards may want to use different applications for a variety of reasons: smart 
cards may have different capabilities, users may have different needs and preferences, users may be 
authorized to use different applications. 

Developers of smart card applications often prefer to develop these applications in a simulated 
environment. In the simulated environment, many hardware elements of the system such as the 
smart card, cardreader and card terminal are simulated. This allows the developer to test and 
develop fimction, eliminate error, and improve performance of the system without the cumbersome 
and costly need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card™ simulation environment suffer the 
drawback that they are unable to simulate an application that deals with multiple smart cards where 
those smart cards have different applications or where the smart cards have different characteristics. 
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Summary of Invention 

The purpose of the present invention is to provide a method and apparatus for simulating a smart- 
card-based computer application. 

An advantage of the invention is that it supports multi-application card environments. Another 
advantage of the present invention is that it allows simultaneous simulation of smart cards with 
different characteristics. A further advantage is that it allows simulation of the smart card, card 
reader, terminal, and user application in a single development workstation. 

In one embodiment of the present invention there is provided a method for a multiple smart card 
simulator. 

Description of Figures 

Figure 1 shows a flow chart describing an embodiment for the present invention; 

Figure 2 shows a flow chart describing an embodiment for the present invention; 

Figure 3 shows a flow chart describing an embodiment for the present invention. 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include available memory, the 
manner in which they handle error conditions, the command sequence to be input or the data 
returned jfrom a command sequence. Smart cards often also have idiosyncratic quirks or bugs. 
These characteristics and quirks must be simulated in order to have an effective simulation. 

The present invention provides a method for providing a multiple smart card simulator. In one 
embodiment, as set out in figure 1, the following steps occur: 

(i) storing a first set of characteristics of a first smart card (step 1 00). These are stored 
in memory in the developer's workstation; 

(ii) creating a first smart card simulator simulating operation of said first smart card (step 
105). The simulator operates by processing data in the same way that a real smart 
card would; 

(iii) storing a second set of characteristics of a second smart card (Step 1 1 0); 
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(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator (step 1 1 5). The simulator operates by processing data in the same way that 
a real smart card would; 

(v) receiving a first input from a first smart card application (step 1 30). As used herein, 
smart card applications refer to user applications running on the developer's work 
station or on a simulated terminal and not to thin or trivial applications rrnming only 
on the smart card; 

(vi) modifying said first input based on said first set of characteristics (step 140); 

(vii) sending a first modified input to said first smart card simulator (step 1 50); 

(viii) modifying said first input based on such second set of characteristics to form a 
second modified input; and sending the second modified input to said second smart 
card simulator (steps 1 55 and 1 60). The second simulator needs a different modified 
input because it has different characteristics; 

(ix) receiving a first output from said first smart card simulator generated in response to 
said first modified input (step 170). The output is generated by the simulator by 
methods known to those skilled in the art; 
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(x) modifying said first output based on said first set of characteristics to form a first 
modified output (step 1 80); 

(xi) transmitting said first modified output to said smart card application (step 1 90); 

(xii) receiving a second output fi-om said second smart card simulator generated in 
response to said second modified input (step 200). The output is generated by 
means to those skilled in the art; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output (step 210); 

(xiv) transmitting said second modified output to said smart card application (step 220); 

In another embodiment, a method is provided for simultaneously running different applications on 
different smart cards. This method is shown on Figure 2 and comprises the following steps: 

(i) receiving a second input from a second smart card application (step 300); 

(ii) modifying said second input based on said first set of characteristics (step 310); 

(iii) sending a third modified input to said first smart card simulator (step 320); 
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(iv) receiving a third output from said first smart card simulator in response to said third 
modified input (step 330); 

(v) modifying first said third output based on said first set of characteristics (step 340); . 

(vi) transmitting said third modified output to said second smart card application (step 
350); 

One important aspect of the invention is the ability to simulate card insertion. Depending on the 
characteristics of the inserted card, different applications may be downloaded into the card. This 
method is shown in Figure 3 and comprises the steps: 

(i) generating a simulated smart card insertion (step 400); 

(ii) determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 4 1 0); 

(iv) determining available applications (step 420); 
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(v) downloading to a simulated smart card and to a simulated terminal at least one smart 
card application (step 430) and 

(vi) repeating (steps 400 - 430) 

In the above methods it may be advantageous to simulate Java Cards, for which many development 
tools currently exist and for which the same program code can run in the actual smart card and in the 
simulator, niEimely the Java programming language. 

Further details are set out in appendix A "Alchemy: Science and Magic for Intelligent Devices" 
especially sections 5 and 5.1 and in co-pending U.S. applications 09/332,069 titled "Method and 
Apparatus for Incremental Download from Server to Client", 09/332,1 91 titled "Method and System 
of Deploying an Application between Computers", 09/332,192 titled "Method and System for 
Remotely Observing and Controlling Objects and 09/332,193 titled "Method and System for 
Managing and Using Persistent Storage all of which are incorporated by reference. 
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We claim: 



1 . A method of providing a multiple smart card simulator comprising: 



(i) storing a first set of characteristics of a first smart card; 



(ii) creating a first smart card simulator simulating operation of said first smart card; 



(iii) storing a second set of characteristics of a second smart card; 



(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator; 



(v) receiving a first input firom a first smart card application; 



. (vi) modifying said first input based on said first set of characteristics; 



(vii) sending a first modified input to said first smart card simulator; 
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(viii) modifying said first input based on such second set of characteristics to form a 
second modified input; and sending the second modified input to said second smart 
card simulator; 

(ix) receiving a first output from said first smart card simulator generated in response to 
said first modified input; 

(x) modifying said first output based on said first set of characteristics to form a first 
modified output; 

Od) transmitting said first modified output to said smart card application; 

(xii) receiving a second output from said second smart card simulator in response to said 
second modified input; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output; and 

(xiv) transmitting said second modified output to said smart card application. 

The method of claim 1 where said characteristics include one of the smart cards memory 
size, command sequence, error handling.routine or quirks. 
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The method of claim 1 further comprising the steps: 



(i) receiving a second input from a second smart card application; 



(ii) modifying said second input based on said first set of characteristics; 



(iii) sending a third modified input to said first smart card simulator; 



(iv) receiving a third output from said first smart card simulator in response to said third 
modified input; 



(v) modifying first said third output based on said first set of characteristics; 



(vi) transmitting said third modified output to said second smart card application. 



A method of simulating a multiple smart card environment comprising: 



(i) detecting a simulated smart card insertion (step 400); 



(ii) determining characteristics of the inserted card (step 405); 



12 



wo 00/77750 PCT/CAOO/00703 



(iii) notifying registered listeners (step 4 1 0); 



(iv) determining available applications (step 420); 



(v) downloading to a simulated card and to a simulated terminal at least one smart card 
application (step 430) and 



(vi) repeating (steps 400 - 430). 
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Figure 1 
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Step 150 


Sending modified input to first smart card 
simulator. 
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card simulator. 






Step 170 


Receiving output from first smart card 
simulator. 




1 

T 


Step 180 


Modifying output from first smart card 
simulator with first set of characteristics of 
first smart card. 




1 

T 


Step 190 


Transmitting first modified output to smart 
card application. 




1 

T 


Step 200 


Receiving output from second smart card 
simulator. 




1 

T 


Step 210 


Modifying output from second smart card 
simulator with second set of 
characteristics of second smart card. 




i 

T 


Step 220 


Transmitting second modified output to 
smart card application. 





wo 00n7750 



2/3 



PCT/CAOO/00703 



Rgure 2 
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Figure 3 
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METHOD FOR A MULTIPLE SMART CARD SIMULATOR 

v 

This application claims priority from U.S. provisional application 60/138,679 
5 filed June 14, 1999. 

Field of Invention 

The present application relates to a method for a multiple smart card simulator, 
and in particular, an application employing multiple simulated smart-cards where 
10 the applications running on, or enabled on, some of the smart cards differ from 
those applications running on, or enabted on, other of the simulated smart cards, 
and where the smart cards may have different characteristics. 

Background to Invention 
15 Smart cards are hardware devices that typically have the shape and size of a credit 
card. Often they have an embedded computer processor, memory and an 
operating system. Often smart cards have stored in their memory information 
related to flie user of the smart card. Such information can include: 

20 (i) personal information, such as name, address, other contact 

information, date of birth, etc.; 

(ii) financial information, such as bank account nimibers and type of 
account, account balances and transaction histories, retirement 
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savings plan information, investment infonnation and investment 
portfolio and account infonnation; 

(iii) medical infonnation, such as medical history and known allergies 
5 and prescription history; 

(iv) information related to retail shopping, such as clothing sizes, 
shopping histories and product, preferences; and 

10 (v) other infonnation relating to taste, style and economic, social or 

cultural activity. 



Smart cards are inserted into card terminals which may include automated teller 
machines, internet kiosks, pay telq>hones, point of sale terminals, cellular phones, 
15 or any device containing a card reader. 



Using the information stored on the smart card, the card terminals provide a 
variety of services and computer-based applications to the user of the smart card. 
These services can include: 

(i) paying bills, transferring money between accounts, making 
investments, analyzing a portfolio; 
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(ii) 



ordering prescription drugs, providing information to health care 



professionals or receiving information from them; 



(iii) 



buying or selling consumer goods, receiving product information. 



participating in consumer surveys, receiving promotional offers. 



customizing products; and 



(iv) 



playing games or receiving other content such as music, video. 



text or images. 



10 



Different users of smart cards may want to use different applications for a variety 
of reasons: smart cards may have different capabilities, users may have different 
needs and preferences, users may be authorized to use different applications. 

15 Developers of smart card applications often prefer to develop these applications 
in a simulated environment. In the simulated enviromnent, many hardware 
elements of the system such as the smart card, cardreader and card terminal are 
simulated. This allows the developer to test and develop function, eliminate 
error, and improve performance of the system without the cumbersome and costly 

20 need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card™ simulation 
environment suffer the drawback that they are unable to simulate an apphcation 
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that deals with multiple smart cards where those smart cards have different 
applications or where the smart cards have different characteristics. 

Summary of Invention 
5 The purpose of the present invention is to provide a method and apparatus for 
simulating a smart-card-based computer appUcation. 

An advantage of the invention is tiiat it supports multi-application card 
environments. Another advantage of the present invention is that it allows 
10 simultaneous simulation of smart cards with different characteristics. A further 
advantage is that it allows simulation of the smart card, card reader, terminal, and 
user appUcation in a single development workstation. 

In one embodiment of the present invention there is provided a method for a 
15 multiple smart card simulator. 

Description of Figures 

Figure 1 shows a flow chart describing an embodiment for the present invention; 
20 Figure 2 shows a flow chart describing an embodiment for the present invention; 
Figure 3 shows a flow chart describing an embodiment for the present invention. 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include 
5 available menDiory, the manner in which they handle error conditions, the 
command sequence to be input or the data returned from a command sequence. 
Smart cards often also have idiosyncratic quirks or bugs. These characteristics 
and quirks must be simulated in order to have an effective simulation. 

10 The present invention provides a method for providing a multiple smart card 
simulator. In one embodiment, as set out in figure 1, the following steps occur: 

(i) storing a first set of characteristics of a first smart card (step 1 00). 
These are stored in memory in the developer's workstation; 

15 

(ii) creating a first smart card simulator simulating operation of said 
first smart card (step 1 05). The simulator operates by processing 
data in the same way that a real smart card would; 

20 (iii) storing a second set of characteristics of a second smart card (Step 

110); 
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(iv) simulatiBg operation of said second smart card thereby creating a 
second smart card simulator (step 115). The simulator operates 
by processing data in the same way that a real smart card would; 



10 



(v) receiving a first input from a first smart card application (step 
130). As used herein, smart card applications refer to user 
applications running on the developer's woric station or on a 
simulated terminal and not to thin or trivial applications running 
only on the smart card; 

(vi) modifying said first input based on said first set of characteristics 
(step 140); 



(vii) sending a first modified input to said first smart card simulator 
15 (step 150); 

(viii) modifying said first input based on such second set of 
characteristics to form a second modified input; and sending the 
second modified input to said second smart card simulator (steps 

20 155 and 160). The second simulator needs a diflFerent modified 

input because it has ditferent characteristics; 

(ix) receiving a first output from said first smart card simulator 
generated in response to said fijrst modified input (stqp 170). The 
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output is generated by the simulator by methods known to those 
skilled in the art; 

(x) modifying said first output based on said first set of characteristics 
5 to form a first modified output (step 180); 

(xi) transmitting said first modified output to said smart card 
application (step 190); 

10 (xii) receiving a second output from said second smart card simulator 

generated in response to said second modified input (step 200). 
The output is generated by means to those skilled in the art; 

(xiii) modifying said second output based on said second set of 
15 characteristics to form a second modified ou^ut (step 210); 

(xiv) transmitting said second modified output to said smart card 
appUcation (step 220); 

20 In another embodiment, a method is provided for simultaneously running 
different apphcations on different smart cards. This method is shown on Figure 
2 and comprises the following steps: 
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(i) receiving a second irput from a second smart card application 
(step 300); 

(ii) modifying said second input based on said first set of 
5 characteristics (step 310); 

(iii) sending a third modified input to said first smart card simulator 
(step 320); 

10 (iv) receivinjg a third output from said first smart card simulator in 

response to said third modified input (step 330); 

(v) modifying first said third output based on said first set of 
characteristics (step 340); 

15 

(vi) transmitting said third modified output to said second smart card 
application (step 350); 

One important aspect of the invention is the ability to simulate card insertion. 
20 Depending on the characteristics of the inserted card, different apphcations may 
be downloaded into the card. This method is shown in Figure 3 and comprises 
the steps: 

(i) generating a simulated smart card insertion (step 400); 
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(ii) 



detennining cbaiacteristics of the inserted card (step 405); 



(iii) 



notifying registered listeners (step 410); 



5 



(iv) 



determining available applications (step 420); 



(V) 



downloading to a simulated smart card and to a simulated 



terminal at least one smart card application (step 430) and 



10 



(vi) repeating (stqps 400 - 430) 

In the above methods it may be advantageous to simulate Java Cards, for which 
many development tools currently exist and for which the same program code can 
15 run in the actual smart card and in tiie simulator, namely the Java programming 
language. 

Further details are set out in appendix A "Alchemy: Science and Magic for 
Intelligent Devices" especially sections 5 and 5.1 and in co-pending U.S. 
20 applications 09/3 32,069 titled "Method and Apparatus for Incremental Download 
from Server to Client", 09/332,191 titled "Method and System of Deploying an 
Apphcation between Computers", 09/332,192 titled "Method and System for 
Remotely Observing and ControUing Objects and 09/332,193 titled "Method and 
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Syston for Managmg and Using Persistent Storage all of which are incorporated 
by reference. 

5 
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APPENDIXA 




Alchemy™: 
Science and Magic 
For Intelligent Devices 
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Acronyms 




API 



Application Programming Interface 



ASCII 



American Standard Code for Infonnation Interchange 



ATA 



Advanced Technology Attachment 



AWT 



CPM 



Abstract Windowing Toolkit 



Comrnxmication Processor Module 



CSO 



Chip Select O 



DSP 



Digital Sig?ial Processing 



DRAM 



EXynamic Random Access Memory 



DSVD 



Digital Simultaneous Voice Data 



DTAD 



Digital Telephone Answraing Device 




HTTP 



Hyper Text Transmission Protocol 




Input/Output 



ISDN 



Integrated Services Digital Network 



ISO 



International Oiganlzation for Standardization 



ISP 



Internet Service Provider 




JNI 



JVM 



Java Virtual Machine 



LED 



Light Emitting Diode . 



LIFO 



Last In. First Out ' 



WR Flash 



Negative OR Flash 
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O&C 



Observatioaand Control 



PIM 



Personal Infonnation Manager 



POTS 



Plain Old Telephone Service 



PPP 



Point-to-Point Protocol 



PSTN 



ROM 



Public Switched Telephone Network 



Read Only Memory 



RTOS 



Real Time Operating System 



SCWTD 



Spontaneous Caller Waiting ID 




User Interface 



URL 



Uniform Resource Locator 
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1 Introduction 

Advances in ioteme^ telephony, and other commimications tedinologies have spurred demand for a wide range 
of new, intelligent devices. Armed with these devices, service providers wiU soon offer a host of new Internet 
services to a new class of users. Easy access to services wDl fuel tiie continuing explosion of tiie Internet, 
uitiniatfily creating greater demand for intelligent access devices. As a device manufacturer, this is the kind of 
chain reaction you want to be right in the middle of. but how do you get in the game? Many devices wiD be 
deployed including screen phones, counter-top tablets, set top boxes, mobile phones, public Idosks, Personal 
Digital Assistants (PDA), etc. Regardless of the device, there are a couple of things to keep in mind, if you are 
going to be successful. 

1 . Your device is going to have to be "slick^ so you can differentiate yourself from the competition. 

2. The time to market is critical so you will want to compress your development time. 

3. Development dollars are scarce so use them where they count the most, on the value add content 

4. People that know how to put Java™ into embedded appliances are very scarce. Work on getting them now. 

5. The Internet is bigger Aan you are, so you need a way to integrate the rapidly emerging technologies 
without gettmg buried. - 

What will it take to get this device developed? 

First, you need a hardware solution. You can probably find a reference design as a starting pomt, but youVe 
going to need to build a development board with the proper features for your device. You need to get started 
right away because it will take 4 to 6 months. Beyond that timeframe, you will also have to spin a form factor 
board, which will take anoth^ 4 to 6 months. 

Next, you need a proper environment and strategy for software development- You need to develop the software 
parallel to the hardware because you won't see the hardware for several months. Java^*^ is a good choice for 
achieving platform mdependence and it has "network awareness"* within it Good news comes from your Real 
Time Operating System (RTOS) vendor because he has an embeddable Java solution you can deploy on your 
hardware when it*s ready. 

It's not a bed of roses yet. you have a full suite of device drivers to v^ite before integrating your software and 
hardware. Better get your RTOS engineers working right away as driver development might end up on the 
critical path. 

Now, let*s move to the application suite. The initial set of applications to be deployed is well defined but the 
dynamic nature of the service environment vwll inevitably give rise to new requirements. You need a solid multi- 
^plication infrastructure that allows you to react to changing requirements. but there isn't time to do it 
properly for this device. 

So, you take shortcuts and begin to cobble together your application suite. Debugging proves to be more 
complicated than expected because the software is multi-threaded. It would be nice to have debugging tools 
tailored to your architecture, but you don't have time or resources to develop tools. You struggle with traditional 
tools and some rudimentary tracing facilities. 

Eventually, you have a "mostly working" application suite and hardware platform. You are ready to begm 
. integration but progress is slow. It proves to be non-trivial to configure a target device properly and get a Java™ 
software load onto it It would be nice to have a seamless enviroiunent covering the entire spectrum from the 
jQva'TM application suite to RTOS and drivers... but you don't Debugging on the target is even more challenging 
tiian on the workstation. You probably should have developed those test tools but it's too late now. 

Finally, your applications are rurming on the target and are close to achieving the functional requirements for the 
device... but you aren't out of the woods yet Your boot time is too slow and your memory requirements are too 
large. You need to re-ardiitect your application suite to improve the initialization sequence. Meanwhile, you find 
tools that can help trim down your Java^w load, but they are not well integrated and prove to be cumbersome. 
You make the tools work for you, but you really need to address these environmental issues before your next 
device. 
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You are ready for field trials, but you had to pull all your diagnostic capabilities to achieve a representative 
software load. You are now flying blind when it comes to debugging anomalies in the field. It would be great to 
have support for remote management and monitoring of the device. You would double benefit jfrom this when it 
comes time to performing automatic regression testing. Put it on the wish list for next time... this device is done! 

It took 18 months to deliver, and cost you over 96-man-months of software effort and 48 man-months" of 
hardware resources. You hope you haven't missed your window of opportunity. The next device will go a lot 
smoother now that you've been through it once. At least yoii hope so! Don't let this description become a brief 
history of your development effort. There Is a better way. 



Alchemy™ 

Derived from real world experience gained in developing two generations of Java-based intelligent devices, 
AudeSi Technologies Inc. delivers Alchemy™, a unique software and hardware solution targeted at rapid 
development of intelligent devices requiring Internet, telephony, and/or smart card capabilities. 

Alchemy^*^ includes a Java-based multi-application software framework, a variety of plug-in software services, 
working example applications, and a comprehensive development and test environment that addresses the fiill 
spectrum of device-level software development issues. Alchemy^, when integrated with Touchstone"™ and 
associated drivers, provides a superset of hardware capabilities required for intelligent devices. This includes a 
PowerPC™ based computation engine, multiple memory configurations, an advanced two-line telephony block, 
smart card readers, and a host of I/O capabilities including Ethernet, modem, serial, and universal serial bus 
(USB). Details on Touchstone™ are included m Appendbc A. . 

The primary goal of Alchemy™ is to reduce the barriers to entry for prospective manufacturers and developers 
of intelligent devices. Alchemy™ achieves these goals by providing the following. 

1 . A Java Native Interface (JNI) provides access to Touchstone™ hardware platfonn capabilities from the 
Java™ layer, thus eliminating the need for developers to work whh low-level device drivers and RTOS 
issues. 

2. The Alchemy™ Core Framework provides a comprehensive environment for the deployment of an 

. extensible multi-application software suite. The framework handles a variety of low-level issues including 
device configuration, initialization sequence, and memory/file-system management, thus allowing the 
developer to concentrate on application level development. 

3. The framework is "Internet Aware" and supports seamless integration with network-based server 
environments. Two primary capabilities delivered through network awareness are as follows: 

• Remote device management where a serverrbased application can manage a device for the purpose of 
device configuration, software upgrade, or in-field diagnostics. 

• Distributed framework services where applications can be seamlessly partitioned across the 
device/server environment, ultimately reducing device resource requirements by offloadmg portionis of 
the application onto server resources. 

4. Alchemy^" is based on the JavaBeans"^ programming model, and as such, facilitates development of 
portable and reusable software components, and integration with commercially available Java™ software 
development tools and environments. 

5. Alchemy™ delivers comprehensive services in support of application development including the following: 

• Application services including application registration, application selection, language management, 
and user preference management 

• Internet services including point-to-point protocol (PPP) and integration of 3"* party browsers and 
email clients.- 

• Smart card services including Open Card Framework™ (OCF) and Java Caid™ support 
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• Telephony services including voice call control state machine, dual tone multi frequency (DTMF) tone 
generation, jfrequency shift keying (FSK) data reception. Calling Line ID/Spontaneous Caller Waiting 
ID (CLID/SCWID), contact database, and modem control. 

• Observation and control services that facilitate remote testing of devices. 

• Device Management Gateway services for secured management of device configuration and 
application download. 

Beyond this initial set of services. Alchemy™ will be continually enhanced with new service offerings in a 
variety of areas mcluding security and cryptographic support, £-Commerce protocols, personal information 
manager (PIM) services, and advanced Internet and telephony services. 

6. Alchemy™ includes Rapid Application Development (RAD) objects that leverage available Alchemy^" 
services into functionally complete application unplementations. RAD objects can be customized to rapidly 
deliver applications with a device-specific look and feel. 

7. Alchemy™ includes a comprehensive set of development tools (e.g., installation tools, system configuration 
tools, debugging and testing tools) that smooth the development process. 

The remaining sections of this paper describe the architecture and capabilities that Alchemy*^)* delivers. 

2 Architectural Overview 

The basic architecture of Alchemy™, as deployed on Touchstone™, is shown in Figure 1 . . 
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Figure 1 — Alchemy™ Architecture 
The major components in the device architecture are described below. 
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1 . Touchstone'^ consists of the reference hardware, the RTOS, device driver suite, the PJava 
environment and the device driver JNL Touchstone™ currently supports two commercial RTOS/Java 
environments, namely Sun's JavaOS4C^, and WindRiver Syst^s' JWorks"^. 

2. Alchemy ^Core Framework: The firameworic is the backbone of the software architecture, providing a 
dynamically configurable multi-application framework and managed bean repository. Managed beans 
represoit the active components in the system, and are directly accessible through the framev/ork. Hie 
framework is also responsible for low-level device infrastructure including system configuration, 
device initialization, communications adapters, memory management, file system, persistent storage, 
and JAR management 

3. Alchemy ^System Beans: A variety of system beans are provided with Alchemy* These beans give 
other application beans access to system services such as hardware devices, persistent storage, system 

. properties-and application support facilities. 

4. Service Beans: General purpose and application-specific capabilities are provided to Ae system 

. through service beans. They are device-indqjendent and reusable in nature. Application beans make 
use of service beans to deliver device-specific application capabilities. While Alchemy^" supplies a 
number of service beans, they are most often associated with specific application frmctionality (e.g., 
the protocol component of an application). 

. 5. Application Beans: The look and feel of a specific application on a specific device is implemented in 
an application bean. An apphcation bean implements the user interface and interacts witii system and 
service beans to achieve the application's intended fimctionality. Alchemy™ provides a number of 
RAD objects that are designed to deliver functional applications quickly. RAD objects can be extended 
or modified to deliver device-specific application features. 

6. Communications Adapter: The communications adapter allows for sever-based communication with 
the framework and all managed beans that are registered with the framework. Adapters provide a 
mechanism whereby managed beans within the framework can be manipulated remotely through a stub 
or client bean. Alchemy™ cunently supports HTTP and HTTPS commtmications adapters. 

The Alchemy™ architecture'provides direct seamless integration with server applications through the 
framework and communications adapters. While the device/server architecture is general-purpose in nature, it is 
currently used whhin the Alchemy™ environment to deliver three key capabilities. 

1 . Device Managemeni Gateway: The gateway is part of the Alchemy™ architecture that supports remote 
management of devices. Through a communications adapter, the gateway can interact with the framework 
to provide a number of capabilities, including discovery services, device configuration, and application 
download. Discovery services are used to determine the existing configuration of a device, including 
available resources, existing software components, and version numbers. Device configuration services 
allow for remote configuration of the services and applications on the device. Application download 
services allow for upgrades to the device software load, including dovniload of new applications to the 
device. The gateway is fully extensible and can be easily incorporated into any server environment 

2. Remote Testing: Because Alchemy™ supports remote interaction with the framework and managed beans 
within the framework, it is well suited to remote device testing. Alchemy^" includes a flexible and 
extensible observation and control architecture that allows a server-based test tool to monitor and control 
the behavior of managed beans within the framework. The observation and control architecture is well 
suited to development time testing, automated regression testing, and m-field testing. 

3. Extended Framework: Alchemy™ directiy supports the concept of an extended framework where a slave 
framework environment is created on the server and controlled by the device. Using this mechanism, it is 
possible to partition applications in a manner that places most of the application resources on the server 
with only the shell of the application deployed on the device itself. Interaction between the device-resident 
application shell and the server-resident application s^vices is achieved transparentiy through the 
firework and the communications adapter. 
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3 Alchemy™ Core Framework 

The framework is the heart of the Alchemy"'" architecture and is responsible for establishing and 
maintaining all basic system services, and orchestrating the device mitialization sequence. The services 
available in the framev/ork are described in the following subsections. 

3.1 System Configuration 

The framework defines the system configuration through a set of system properties. These properties define 
precisely the underlying capabilities of the device and include information regarding available memory, 
display capabilities, and the existence of I/O devices such as Ethernet, USB, modem, smart card reader, etc. 
In essence, the system properties defme a subset of Touchstone™ capabilities that are available to a device- 
specific software load. System preppies can be defined through a combination of hard-coded, command- 
line, and property-file entries. After initialization, system properties are made generally available through 
the standard Java system properties. 

The system properties can be accessed remotely throu^ discovery services in the gateway. 

3.2 Persistent Storage 

Alchemy^^ relies on the existence of some form of persistent storage. At a minimum, persistent storage is 
required to hold the software load itself; To take advantage of the dynamic capabilities of Alchemy, 
writeable persistent storage is required. Beyond storage of the system itself, the framework controls all 
other persistent storage and makes it available to managed beans within the system. A variety of flavors of 
persistent memory are supported including NAND Flash, NOR Flash, and EEFROM. Touchstone™ 
provides underlying hardware and driver support for all types of persistent memory. 

Through a set of configuration parameters, the developer can defme any number of contiguous blocks of 
persistent storage within the systems available persistent memory. Once deJBned, tliese persistent storage 
blocks are available for allocation to managed beans through the framework. The framework is responsible 
for maintaining a persistent map of persistent storage, and returning the blocks to their respective owners at 
start-up. The framework is also responsible for de-allocation of persistent storage and defragmentation of 
persistent memory. 

Although Alchemy™ does not rely on the existence of a Flash File Systran (FFS), it does siipport one. If a 
device is configured with a FFS, it will exist in a contiguous block of Flash and be made available through 
tfie standard Java file system support. The FFS can co-exist with the block-based persistent storage 
mechanism provided by the framework. 

3.3 JAR Repository 

The Java software load for a system is maintained in Java Archive Storage (JAR) files in persistent storage. 
The JAR Repository is responsible for managing the JARs and adjusting the JVM CLASSPATH to include 
all available JARs. JARs are separated into three categories as follows: 

1 . Java System: The Java System JARs include all the base Java classes the virtual machine (VM) expects. 

2. Alchemy ^System: The Alchemy"^** System JARs contain the enthe core Aldiemy''" classes used in the 
system including Alchemy^** utility, system, and service classes. 

3. Application; Application JARs contain the device specific application and service classes for a system. 

The CLASSPATH is dynamically constructed with Java System JARs first. Alchemy^** System JARs next, 
and Application JARs last. Within each subset of the CLASSPATH, JARs are maintained in reverse order 
of their registration (e.g., last registered JAR is first), hi this way new JARs can replace obsolete classes in 
older JARs. The JAR Repository can be managed remotely through the gateway to add and remove JARs 
from the system. The JAR Repository is not dependent on a file system, and all JAR downloads are 
"guaranteed". 
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3.4 Managed Bean Repository 

Managed beans represent the active compon^ts in the system, and collectively, implement the capabilities 
of the device. The framework is responsible for maintaining a persistent repository of managed beans, and 
making those beans generally available in the system. The following information is associated with each 
managed bean in the system. 

1 . Name: The name used to reference the bean. 

2. /i>:-A unique identifiw for the bean. 

3. Cia&r The fully qualified class name for the bean. 

4. Type: The type of bean. 

5. Persistent Storage Block List: A list that identifies the persistent storage blocks belonging to the bean. 
When a bean is registered with a repository, it must have a unique name. In turn, the bean is assigned a 
-peraianent unique identifier. A reference to any bean in the repository can be obtained through the 
framework using either the name or fee ID of die bean. 

3.5 Communications Adapters 

The framework is responsible for establishing any communications adapters that exist in the system. 
Configuration parameters are used to define which adapter is used Alchemy™ supports HTTP and HTIPS 
adapters. If an adapter is not included in the device configuration, remote services will be unavailable. 

3.6 System Initialization . 

The framework is responsible for performing system initialization. The primary goal of the initialization 
sequence is to bring the device to life quickly and then complete system initialization in the background. 
The following phases make up the initialization sequence: 

1 . The framework establishes its environment including system properties, framework, persistent storage 
maps, and managed bean repository. 

2. The framework establishes application services through creation of the application manager. The 
application manager is discussed m section 4.1 , 

3. The framework creates and registers all application type managed beans. At regisn^tion time, managed 
beans are given the opportunity to perform required internal initialization. While not enforceable, 
applications should avoid extensive initialization work at registration time. Wherever possible, object 
creation and initialization within an application should be deferred to the moment that such objects are 
required. 

4. Once all applications are registered, control is transferred from the framework to the application 
selector where the defauh idle application is started. Idle applications are discussed in section 4.1 . 

5. In the background, the frameworic continues to create and register other managed beans in the system 
until it has exhausted the list contained in the managed bean repository. Should a running application 
requne access to a bean that has not yet been initialized, that bean will be created arid registered at the 
time of the request. 

3.7 Idle Detection 

Idleness of a device can be used to trigger a number of activities ranging from activation of a screen saver, 
to performing systems maintenance activities such as defragmentation of persistent storage. Alchemy™ 
provides an idle management service that controls the idle detection process and dispatches events 
indicating system idleness. Two mechanisms are provided for indicating activity in the system. 

1, Spontaneous: The idle manager provides a direct API used to indicate current activity. Any object in 
the system can indicate current activity by making this call. 
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2. Foiling: Objects in the system can act as polled activity sources by registering with &e idle manager. 
The manager uses a configurable idle timer to set the polling period On each timer expiration the 
manager polls each source for activity status. 

On each idle timer expiration, the manager decides if the device has been idle during feat period. If it has, 
the manager generates events to all idle listeners. Idle events include an idle count indicating the current * 
number of consecutive idle p«iods. Listeners can use this count to distinguish between varying levels of 
idleness. The idle management architecture is iUustrated m Figure 2. 





Figure 2 - Idle Management Architecture 



4 Application Services 

One of Alchemy's primary goals is to provide an environment that allows the developer to focus on 
application-level development Towards this goal, Alchemy™ provides an extensible multi-application 
architecture in which applications can co-exist. In addition. Alchemy^ provides a number of common 
application services and RAD objects that further reduce the development cycle for applications. 
By definition, an application must include some user interface component (a means by which tlie user 
interacts with the application). Unlike traditional computing environments, it is not a certainty that an 
inteUigent device win inchide a full-featured, point-and-click windowing environment in which the user 
interface (UI) can be deployed. Alchemy^" provides fte necessary infrastructure to support the following 
display environments. 

1. Abstract Windowing Toolkit (AWT) Windowing Emiromnent: This is the standard Java GUI 
envhonment that supports graphics, windows, and a pointing device. Standard AWT-based drawing 
components and event mechanisms are applicable to this environment 

2. Sea-of-Dots Graphics Environment: This type of display supports rudimentary bit-mapped graphics, 
icons, and text A pointmg device is not normally associated widi this envirormient Configurable soft 
keys may be associated with this environmerit 

3. Alphanumeric Display Environment. This type of display supports some number of lines and columns 
of alphanumeric style text and fixed-size icons. Configurable soft keys may be associated with this 
environment 

AIchemy*s application services are organized into display-independent and display-d^dent capabilities. 
Display-mdependent services include the multi-application architecture, options management, and language 
management, which are described in section 4.1 through 4.3. Display-dependent. services for the three 
display environments are described after the display-independent services. 
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NOTE: The first release of Alchemy"™ includes only AWT-dependent display services. Sea-of-dots and 
alphahuineric display services are deferred to a subsequent release of Alchemy. 

4.1 Multi-Application Architecture 

The multi-application architecture in Alchemy™ is supported through an Application Manager that 
provides three basic services as illustrated in Figure 3 and described beJow: 

1 . Application Registration: Before applications are available for selection they must be registeretj with 
the Application Manager. The registry maintains a reference to each application and can activate and 
deactivate applications on demand. Within the registry, a single application is identified as the idle 
application, which is activated automatically at start-up, and whenever the device becomes idle. The 
registry also generates events indicating when the set of applications is modified. This event 
mechanism supports dynamically modifying the set of available applications. 

2. Application Selection: Applications are given focus and made active by the user through an application 
selector. The application selector interacts with the registry to present the user with a selection of 
available applications and effects the activation of applications when they are selected. By definition, 
an Explication selector includes some UI component, and as such must be implemented for a specific 
display envkonment. Alchemy^" provides both display-indepaident services for application selectors 
as well as display-specific RAJD implementations of application selectors. 

3. Application History. A history is maintained when applications are activated and de-activated. When 
an active application is deactivated, the application history determines which application should be 
activated. Alchemy™ provides the base services for application history, as well as a RADO 
implementation of a configurable, fixed-depth, LIFO history. 



^^^^^ 




Figure 3 - Multi- Application Architecture. 



4.2 Options Management 

Most device envm)nments have a requirement for persistent, user settable options. These options range 
from global options that apply across the eotu-e device (e.g., language preference), to application or service 
specific options. While the scope of options may vary, user access to cations is typically available through 
a common access point In a dynamic application environment it becomes necessary for options 
management to become dynamic as well. Alchemy™ provides an extensible options management service 
that facilitates the organization of options, without imposing a specific implementation of options 
management at the Ul level. TTie options service in Alchemy™ i^ovldes a base infrastructure.that includes 
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an options menu object capable of supporting a hierarchically representation of options and submenus of 
options, and an abstract option screen object Jfrom which an actual options editing implementation can be 
derived. Furthermore, the options manager contains a medianism for identifymg start-up options that must 
be set on initial stert-up or each time the device is activated: Hie options management architecture is 
illustrated in Figure 4. 




Startup ^ 
List 



. Menu 
Heirarchy 



Options 
Screens 



Figure 4 - Options Management Object Relationship 



Key elements of the options architecture are as follows: 

1 . Options Management Applications This is the application responsible for presentmg the common 
access points to options. * • 

2. Options Management Service: This Alchemy™ service provides a root menu and a start-up list for the 
system. 

3» Root Menu: This is the root of the options tree. Options and submenus can be added, as required. 

4. Startup List: This is the list of options that need to be initialized at device start-up. These options must 
be set on initial start-up or each time.the device is activated. 

5. Options Screens: These are the actual GUI implementations of options editing screens for the available 
options. 

6. Invocation Indications', Alchemy^" decouples the invocation of an options screen from the user's 
dismissal of the screen. When the option screen is dismissed, the invocation indication is used to 
inform the controDing application that user manipulation of the options screen is complete, 

4.3 Language Management 

Alchemyf" provides a language management service that mamtains a list of available languages and a 
listener interface that supports notification of language changes. In addition, Alchemy™ provides a base 
language mterface and a core language nnplementation from which application specific language object 
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4.4 AWT Services 

In an AWT-style application environment, the developer has access to all AWT services supplied with 
PJava. While AWT services foiro the basis of the GUI application. Alchemy™ provides a number of 
services, mterfaces, and objects that tightly couple the AWT-based application to the multi-application 
architecture. 



4.4.1 Applications, Icons, and Selection 

AWT applications extend the base application interface with two objects, a generic panel, and an 
Alchemy"^ specific AWT icon. The panel is used to house the GUI for the application itself. Whenever the 
^plication is activated, the panel is displayed. The icon is used to effect application selection. It contains 
an image associated with the application and a reference to the application. The icon generates "application 
selected'* events when a mouse click occurs on it. The sequence involved in selection of an application is 
described below and illustrated in Figure 6. 

1 . A mouse click in the application icon generates an "application selected ev^f * which is received by 
the application selector. 

2. The application selector makes a request to the application manager to activate the application. A 
reference to the application is supplied from the application icon. 

3. The application manager informs the application to activate and requests a reference to the application 
display panel. 

4. The application manager displays the panel and control is turned over to the application. 
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Figure 6 - Application Selection 



To speed development, Alchemy provides an AWT application RAD object that implements a shell 
application. This RAD object can be extended to achieve specific application functionality. 

4.4.2 Appiication Selectors 

Alchemy™ provides an abstract base class for AWT application selectors. Several RAD AWT application 
selectors are also included with Alchemy^. 

4.4.2.1 Sidebar Selector 

The AWT Sidebar Application selector implements an icon strip along one boarder of the screen that 
contains a set of icons associated with the device. When an icon is selected, its associated appiication is 
selected and displayed on the remainder of the screen. Scroll bars become active when the number of 
application icons exceeds the available real estate available to the sidebar. The sidebar application selector 
is illustrated in Figure 7. 




Figure 7 - Sidebar Application Selector 
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4.4.2.2 Corner Selector 

The AWT Comer Application selector implements a small icon in the comer of the screen that expands into 
a grid of application icons. When an icon is selected, its associated application is selected and the selector 
minimizes in the comer. The comer ^plication selector is illustrated in Figure 8. 



4.4.3 Options Manager 

Alchemy™ provides a RAD object that implements a pull-doWn-menu-based options management 
application. It dynamically maintains the nested options associated with a device, and provides access to 
those options through a nested puD-down menu. The options manager supports options screens that are 
implemented as panels. 

4.4.4 Virtual Keyboard 

Because many devices will be touchscreen-based. Alchemy™ provides full virtual keyboard support 
including an image-based, configurable virtual keyboard, and a virtual keyboard manager that provides 
tight integration between the vhtual keyboard and text fields within an application GUI. 

The virtual keyboard is based on a multi-image architecture where a visible image contains the user's view 
of the keyboard, and an underlying invisible image provides a mapping to key values. Mouse clicks on the 
visible image are mapped by location (X, Y) onto &e invisible image and the corresponding value in the 
invisible image is converted into a key value. The virtual keyboard generates all standard AWT key events. 
The virtual keyboard also supports automated image replacement based on key presses. For example, when 
the shift key is pressed, the keyboard image can be changed to indicate capital letters. 

When active in a system, the virtual keyboard is automaticaDy displayed when a text field gains focus. The 
text field is reproduced on the keyboard and input is accepted from the user. After completion of the entry, 
the keyboard disappears and the text field is updated to contain the appropriate text. While this mechanism 
is automatic and requires no special considwation from the GUI developer to function, it can be 
cumbersome within a GUI implementation. First of all, the virtual keyboard covers the text that is bemg 
edited, so auxiliary information associated with the field (e.g., a field description) is likely to be hidden. 
Secondly, there is no general-purpose mechanism available to identify a particular keyboard style to 
associate with a particular text field. Lastly, moving from field-to-field involves dismissmg the keyboard 
when one field is completed and re-displaying it when another field is given focus. Alchemy'** overcomes 
these problems by providing a virtual keyboard manager. 

The virtual keyboard manager tightly couples a set of text fields in a GUI implementation to the virtual 
keyboard by providmg the following capabilities. 

1. A field descriptor can be associated with a text field that is registered with the manager. This 
description will be displayed on the keyboard while the text is being edited. 




Figure 8 - Corner Application Selector 
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2, A specific style of keyboard can be associated with a text field that is registered with the manager, 

3. "Tab-oFdering" can be established for a group of text-fields^ ,where the keyboard can be used to 
navigate from field-to-field without being dismissed and redisplayed. 

An application environment that leverages the virtual keyboard manager can be made more user-friendly 
than one that does not 

Alchrany™ comes with a number of RAD virtual keyboards including standard qwerty, alphanumeric, and 
keypad styles. 

4A5 Activity Source 

In support of idle detection mechanism, Alchemy™ provides a polled activity source for AWT 
environments. This source monitors AWT mouse and key events, and provides an indication of activity to 
the idle manager when polled This source elhninates the need for individual appUcations to continually 
indicate activity to the idle manager (based on the premise that if the user is interacting with the device 
through the mouse or keyboard, then some q)pI]cation on the device must be active). 

5 Smart Card Services 

An implementation of the Open Card Framework (OCF) is the cornerstone of Alchemy *s smart c^d 
services. OCF is implemented within Alchemy™ as a service bean and includes terminal and tenninal 
factory implementations for the ARP smart card reader, as well as a number of S^** party readers including 
the Gemplus GCR410 and Litronic 210. Usmg OCF, it is possible to support any smart card application by 
implementing an OCF service for the card application, and a terminal application that uses the service. 
Alchemy™ includes a number of RADOs that act as example service and terminal application 
implementations* 

Because Alchemy™ is a dynamic multi-application enviromnent, it is designed to support multi-application 
card environments. To begin with. Alchemy™ provides a card detection service capable of asynchronously 
detecting card msertions and removals, and notifying registered listeners. When a card is inserted, existing 
OCF services are leveraged to detemilne the available card applications and a list of those applications is 
returned to the listener. Based on this list, an application selector or some other service within the device 
can select and activate a particular terminal/card application pair. 

Alchemy™ also supports dynamic download of smart card applications including both terminal and card 
resident portions of a smart card application. Download support is delivered through the gateway as 
described in section 8.4. Specific OCF services are available in Alchemy™ which support the actual 
download of applications to the card. 

NOTE: The first release of Alchemy™ includes support for the Java Card environment only. Support for 
MultOS and other multi-application environments is deferred to a subsequent release of Alchemy^***. 

Fmally, tiie OCF service is augmented with observation and control mechanisms that support remote 
monitoring of ISO 7816 messaging at the card temiinal. This capability facilitates debugging and testing of 
smart card applications. The observation and control architecture is described in section 8.1 . 

5,1 Java Card 

Alchemy™ provides direct support for the Java Card 2.0 and 2.1 environments including a full 
implementation of the Java Card simulation environment Simulation support is realized through the Java 
Card simulation manager, which allows &e developer to create any number of simulated terminals and any 
number of simulated Java Cards. Each sunulated card can be configured to contain a numbo- of real Java 
Card Applets. The manager controls the insertion and removal of a simulated card into a simulated 
terminal. Once card insertion occ\irs, the interaction between card applets and card terminal applications 
can occur just as in a real Java Card environment. Using the simulated envirotmient, it is possible to 
develop a card applet and terminal application in the workstation environment and then migrate it to an 
actual termmal/caati environment Alcfiemy*s Java Card environment is iDustrated in Figure 9. 
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The Java Card simulation manager is augmented with observation and control mechanisms that support 
remote control of card insertion and removal See section 82 for details. 



Simulated Java 
Card En^nronment 



Actual Java Card 
Environment 




Figure 9 - Java Card Environment 



Alchemy 's implementation of OCF contains specific services that support download and deletion of applets 
on a Java Card. This support is leveraged by the gateway to achieve remote management of the application 
suite on a Java Card, See section 8.4 for details. 

6 Telephony Services 

Alchemy^" provides a number of telephony services including modem support, basic telephony support, 
and advanced telephony support These services are described in the following subsections. 

6.1 Modem Services 

Modem services are based on Javax.comm, which defines a standard mechanism for serial communications 
in Java. The modem service ext^ds the Javax.comm serial I/O API with a modem control API that 
provides the functionality to initialize and configure the modem. The existing implementation is targeted at 
the V.90 modem available on Touchstone™, but die modem service is easily portable-to other modem 
solutions. 



6,2 Basic Telephony Services 

The basic telephony services available in Alchemy™ are closely coupled to tiie Touchstone™ Telephony 
board capabilities. The basic telephony service bean provides a control API for direct control over telephony 
features, a status API for retrieving telephony status, and an event listener API for reception of asynchronous 
telephony events. All basic telephony services are summarized in the following table. 
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Table 1: Basic Telephony Services 



Feature/Description 


Control 


status 


Event 


Initialization/Register Control 


X 






Vohnne 








Handset 


X . 


X 




Speaker 


X 


X 




CAS Detection 






X 


FSKDataFleception 






X 


Type I Caller ID 






X 


Type H Caller ID 






X 


Visual Message Waiting 






X 


DTMF Tone Generation 


X 






Ring Detection 






' X 


Extension In Use Detection 




X 


X 


Distinct Audible Ring Tones 


X 






Voice Path Control 








Handset 


X 


X 




Handsffee 


X 


X 




Microphone 


X 


X 




HoId/Mute/anmute 


X 


X 




Dial Pad Scan 






X 


Cradle Hook switch Scan 




X 


X 


Hook Switch Control 








On/Off hook 


X 


X 


X 


Flash 


X 




X 



6.3 Advanced Telephony Services 

While the basic telephony services described in the previous subsection provide access to all the telephony 
capabilities of the ARP, and as such, give the developer fine-grained control over these capabilities, the 
onus IS on the developer to integrate these capabilities into a functional telephony sovice. Alchemy'™ 
includes a number of advanced telephony services that provide this higher level of integration, thus 
reducing the development effort required to deploy a telephony application. Advanced telephony service 
include the foUowing: 

1 . Voice Call State Machine: Provides intelligent control of incoming and outgoing voice paths with 
control over handset/handsfree modes, hold, and mute. Also includes persistent volume control for 
both handset and handsfree, and persistent audible ring tone selection. 

2. Hook Switch State Machine-, Provides integrated control and feedback of the hook switch and hook 
switch cradle. 
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3. Telephony/Modem Line Sharing State Machine: Provides intelligent sharing of the line between 
telephony and modem functionality in a single-line environment. 

4. Distinctive Ring Interpretation: Provided the ability to define distinctive ring interpreters that can be 
used m conjunction with CLID and other services to uniquely identify incoming calls. 

5. Audio Streaming and Playback: Provides voice path control and decompression streams for the audio 
protocols supported on the ARP. 

6. Contact Database: Provides a configurable contact database that tightly integrates with CLID features. 
Provides underlying capabilities for caller log, prefeired name matching, area code striping, etc. 

Alchttny includes a set of RAD objects that implement a full-featured telephony application based on the 
advanced telephony features described above. Hiis application serves as both an example, and a starting • 
point for a device specific telephony application. 

7 internet Services 

Alchemy™ provides seamless access to the Internet, and as such, is designed to develop "Internet Aware" 
devices. Specifically, Alchemy™ provides connection services, integration of 3"* party Internet applications 
such as browsers, and email clients, and custom URL handling for services and applications that re6uire 
integration with browser services. 

7.1 PPP and Auto Dial 

Dialup connectivity to the Internet via an ISP is supported through Alchemy*s Point-to-Point Protocol 
(PPP) and Auto Dial service. The PPP and Auto Dial service maintains a persistent list of ISP 
configurations. Each configuration contains the information required to make an ISP connection including 
phone number, user ID, password, DNS Addresses, mail server, etc. The PPP and Auto Diai service 
provides an API that supports addition, deletion and selection of ISP configurations. Once selected a 
particular configuration is used to automatically establish a connection when some other service or 
appHcation activates TCP/IP services. The PPP and Auto Djal service is also remotely controllable through 
observation and control services. 

7.2 Internet Applications 

Alchemy™ does not reinvent the wheel when it comes to hitemet applications such as browsers and emaH 
clients. A number of Java-based "embeddable^' Internet application suites are commercially available from 
3 party vendors, and these application suites can typically be integrated into Alchemy^ with little effort. 
Alchemy™ has been demonstrated to work with two Internet applications suites, namely Sun 
Microsystems' Personal Applications™ suite, and Espial Group's Escape™ browser and Ebox™ email 
clieixL While Alchemy™ provides integration for these application suites, the suites must currently be 
obtained directly from their respective vendors. 

7.3 Custom URL Handling 

The existence of a browser on a device is useful for more than just traditional Intmiet browsing applications. 
The HTML rendering capabilities of the browser can be leveraged into ofter on-device applications to deliver 
UI services. In such an environment, the developer can use custom URL defmitions to trigger events m other 
services or appHcations. Alchemy™ provides a custom URL dispatching service capable of maintaining a list 
of custom URL types, and a set of listeners for each type. When the browser encounters an unknown URL 
type, jt hands it to the dispatcher which, in turn, dispatches the URL to all interested listeners. 
This process is illustrated in Figure 10. 
As an example, consider the followmg: 

Alchemy:saveToDirectory?name=AudeSi Technologies Inc.&number=403-73(K7555 
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This URL is not recognized by the browser so it is passed to the Custom URL dispatcher. It is then passed ' 
to the URL listeners. One of the listeners is the directory application that takes the URL and fidds-a new 
entry for AudeSi Technologies Inc. 





Figure 10 -Custom URL Dispatching 



8 Observation and Control Services 

The distributed nature of the Alchemy^" core provides direct support for remote instantiation of objects into 
a device load. Leveraging this mechanism. Alchemy™ delivers a complete observaton and control (O&C) 
architecture capable of supporting system debugging, remote diagnostics, automated regression testing, and 
device management 

8. 1 Observation and Control Architecture 

The O&C architecture delivers two key capabilities to the developer. 

1. Observation: The ability to extract information from the system is accomplished by implementing a 
specific observable interface within an object, and remotely controlling the observation process 
through an observer bean. Actual observations are passed from the device through a remote event 
mechanism. Observations can be generic (e.g., text-based logging) or specific (e.g., ISO 7816 

messaging). 

2. Control: The ability to remotely control objects in the system is accomplished by implementing a 
specific controllable mterface within an object and remotely controlling that object through a^controller 
beaiL Control functions are typically object specific in nature. 

Alchemy's™ O&C architecture and its major components are described below and illustrated in Figure 1 1 . 

K O&C Registry: On the device side, the O&C registry is responsible for maintaining a list of all 

observable/controllable objects in the system. The registry communicates with a remote O&C manager 
to orchestrate a specific O&C session. All observable/controllable objects in the system must registo- 
with the registry to be actively observable/controllable. 

2. Observable/Controllable Object: Any object in the system is observable/controllable if it implements a 
specific observable/controllable interface, and it registers itself with the O&C registry. The object is 
manipulated through a mated observer/controller object that knows the specific O&C interface 
implemented by the object 

3. Observer/Controller Managed Bean: On the device side, the Observer/Controller is instantiated as a 
temporary managed bean, and is responsible for manipulating observable/controllable objects of a 
specific type. The observer/controller is remotely controlled by the O&C manager through a matching 
client bean on the server side. 
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4. Observer/Controller Client Bean: On the server side, the O&C manager transparently communicates 
with the device side observo'/controllCT through the observer/controller client bean. 

5. O&C Manager, The O&C Manager controls tiie observation process through three primary fiinctions. 

I. The managw maintains a registry of observer/controllers that can be activated in the framework. 
When instructed to do so by some controlling test tool, the manager instantiates and activates an 
observer/controller in the framework. 

IL The manager presents a configuration and control interface for test tools. It identifies all available 
observer/controllers, and allows the test tool to configure, activate and deactivate those objects. 

IILThe manager processes observation events and submits th«n to observation database. 

6. Observation Database: The Observation Database stores all the observations for a session. Each 
observation is stored with a time-stamp, an observation class name, and the actual observation object. 

7. Test Took Any controlling application can act as a test tool. A test tool may present a GUI to the user 
that allows hhn to configure, activate and deactivate observer/controllers m the system, or it may be a 
self-contained automatic test-harness. Test tools interact with the O&C manager to control an O&C 
session, and with the observation database to inspect observations. 



Observable/ 
Controllable 
Object 



O&C 
Registry 



Observer/ 
Controller 
Client Bean 




Observer/ 
Controller 
Managed Bean 



Figure 11 - Observation and Control Architecture 



Because the O&C architecture is open and extensible, it can be leveraged to deliver any specific O&C 
capabilities applicable to a particular device or service. Alchemy™ provides specific O&C capabilities 
through a number of tools, and observable/confroUable objects as described in the following subsections. 



B.2 Alchemy Observer/Controllers 

Alchemy*™ provides a number of specific observer/controllM- objects that can be used directly by the 
developer including the following: 

1. • Text-based Logger: This observer perfonns generic text-based logging of events, and can be used for 
general-purpose tracing. 
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2. Application Selection Observer: TTiis observer g^erates observations that indicate application 
selection and de-selection activitieSi 

3. ISO 7816 Observer, This observer generates observations for all smart card messaging that occurs 
between an OCF terminal and a smart card. 

4. Java Card Simulation Observer/Controllen This observer/controller interacts with the Java Card 
Simulation Manager to identify available simulated Java Cards and facilitates simulated insertion and 
removal of those cards into a simulated terminal. 

5. Basic Telephony Observer. This observer handles all basic telephony observations generated by the 
Alchemy™ basic telq>hony service. 

6. Persistent Storage Observer: This observer generates observations that contain persistent storage block 
maps. 

7. Modem Observer: This observer generates observations that include ail control commands sent to the 
modem. 

8. PPP and Auto Dial Observer: This observer generates observations that identify all activities 
associated witii PPP coimections. 

8.3 Alchemy Probe 

Alchemy™ inchides a developers' probing tool. This tool provides a controlling GUI that is used to 
establish and control an O&C session. The probing tool was developed to support testing of Alchemy™ 
and as such, worics with all Alchemy™ supplied observer/controllers. The probing tool is based on an 
extensible architecture and can be easily modified to support any custom observer/controller. Tlie main 
features are described as follows: 

1. Cotfiguration: Developers can configure an O&C session by establishing a connection to the device 
under test, and identifying the specific observer/controllers that are active. 

2. Watchpoints: Developers can set watchpomts for particular observations of interest. 

3. Filtering: Developers can defme filters on the properties of the observations. 

4. Database Interaction: The probmg tool provides complete integration with the observation database 
for the storage and retrieval of observations. You can also archive and playback previous sessions. 

5. Formatters: Observations are not necessarily in human-readable fonn. TTie probing tool provides the 
infrastructure to support custom interpreters that can interpret and display specific observations. 

6. Controller Interfaces: The infrastructtire supports custom user interfaces that can be used to activate 
the control interface of observer/controllers. 



1. 



8.4 Device Management Gateway 

The Device Management Gateway provides remote management facilities for devices under development, 
as well as deployed devices. Hie gateway is based on the Alchemy™ O&C architecture and delivers the 
following key capabilities: 

Discovery: This process involves determming the precise configuration of a device. Specifically the 
following information can be retrieved from a device: 

J. System Properties: System properties can be retrieved either individually or as a group. 

II. Managed Beans: The managed bean repository can be queried for the existence of an individual 
bean or for a list of all existing beans. Managed bean queries return bean name, class, version, and 
dependency information. 

III. JARs: The JAR. repository can be queried for a list of JARs and their CLASSPATH ordering. The 
amount of firee space in the repository can also be determined. 
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IV. JcTfa Cards\ Card terminals can be queried for die existence of Java Cards, and subsequently, each 
Java Card can be queried for a list of Java Card applets. 

2. Bean Management', This process involves manipulating the set of managed beans that exist in the 
device. Managed beans caii be added, replaced, and removed. In effect, this service allows ifae 
application and service suite on the device to be customized remotely. Download services include 
automatic instantiatiori of new applications, automatic device restart (where required), and robust 
recovery from failed downloads. 

3. JAR Management, While bean management services automatically support downloading of new JARs 
associated with new applications and services, the gateway supports direct manipulation of JARs that 

• exist in the JAR repository. Specifically, the gateway supports reordering of JARs in the JVM 
CLASSPATH, explicit deletion of JARs, and defiragmentation of the JAR repository itself. 

4. Java Card Management: A Java Card that is inserted into an available card terminal can be managed 
.through the gateway. Specifically, applications can be downloaded to the card or deleted from the card 

The gateway is implemented as an observer/controller managed/client bean pair, and as such, provides 
gateway capabilities to any server side controlling application. Within Alchemy™, gateway facilities are 
deployed into the probing tool through a custom control/mterpreter mterface. This interface acts as an 
example deployment of the gateway that can be modified for a particular service environment, but also 
delivers full-featured gateway capabilities to the developer. ^ 

9 Development Environment 

The underlying goal of Alchemy™ is to reduce the development cycle for intelligent devices by providing a 
software infrastructure and service suite that can be rapidly deployed onto a hardware reference platform. 
WhDe application development can be accomplished in any enviromnent that supports Java, ultimately the 
Java code must be deployed into the target device on top of a properly configured RTOS/driver load. The 
Alchemy*™ development envuormient supports this process through a set of utilities and tools that augment 
and enhance your preferred development envirorunent, without imposing a specific environment or tool 
chain on the developer. Furthermore, all Alchemy™ tools and utilities are written in Java and are delivered 
with full source code so that they can be tailored specifically to a preferred environment This means 
familiar development tools such as Java Integrated Development Environment (IDE), RTOS IDE, and code 
compactors such as the Embedded Java toolchain can be woven together into a seamless development 
environment tailored specifically to your needs. While the development environment is adaptable to any 
hardware target. Alchemy™ provides specific integration for Touchstone"™, and will work with it out of die 
box. 

Alchemy™ includes support for the following aspects of the development cycle: 

1 . Installation: Installation wizards and scripts are included that perform a complete mstallation of the 
Alchemy""* system into your development environment. 

2. Development, Alchemy™ includes a complete makefile structure that will build all Alchemy^" 
software components. This structure can be easily extended to include new applications and services. 

3 . Packaging: Alchemy™ provides packaging tools that perform the following functions: 

I. System Configuration Definition: Allows the developer to specify a particular hardware 
configuration that will be supported for a particular device. 

II. RTOS/Driver Configuration: Based on system configuration information, a RTQS/driver 
configuration can be automatically generated. 

III. Application Suite Definition: Allows the developer to define an application load for deployment 
onb a device. All application/service bean dependencies are automatically resolved to ensure a 
complete load. 

IV. Code Compaction and Ohfuscation: Based on a defined application load, code compaction and 
obluscation can be performed to mmlmize the memory footprint of the load. 

V. JAR Creation: Single or multiple JAR files can be produced for download to the device. 
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4. Tea-get Deployment: Alchemy"™ includes boot-loader facilities for Touchstone'™ that are capable of 
downloading a target software load to the device. Support is available for stand-alone loads as well as 
networic-based loads, 

5. Test/Debug: As described earlier. Alchemy™ supports a remote observation and control environment 
for target testin g and debugging. A number of test and device management tools are d^Ioyed under 
this architecture, including the probing tool and the gateway. 
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10 Appendix A - Touchstone™ 

Touchstone'™ is a two-board solution composed of a logic board that contains central processing and the 
bulk of the I/O cqjabilhies, and a telephony board that includes the telephony and modem capabilities. The 
functional specification for each of these boards is given below. 

Logic Board Functionality 

1 . MPC823(E) Processor Socketed 

2. Core Memory 

• CSC boot Flash - 4 Mbytes of onboard Flash, Full 32 bit interface 

• Nand Flash ~ 4 to 8 Mbytes of onboard, 16 bit interface 

• Compact Flash memory expansion (2-48 Mbytes modules) 

• ATA interface vs. linear Flash will be dependant on existing Java 0S4C (i.e.. Chorus) support 

• 32Mbytes (max.) dedicated onboard SDRAM operating at the maximum processor bus speed. 

3. MPC82xLCDControiler 

• Common onboard LCD interface to provide complete access to all on chip LCD pins or dedicated 
LCD controller 

• Dedicated onboard LCD/CRT Controller with 256Kxl 6 dedicated video DRAM, H/W provision 
only, EPSON SED1355/6FQA - for part details www.erd.epson.com 

Tcarget LCD for Reference Board 



Manufacturer 


Part Number 


Pixels 


Display Area 
(H) X (V) mm 


Technology 


Sharp 


LQ64D341 


640 X 480 


130x97 


TFT Color 



4. 3^ Party Resistive Touch screen 

5. Keypad, status indicator Interface 

• Offboard 2mm header to accommodate up to 6 x 6 keyscan matrix 

• I^C connections to provide 8 incremental GPIOs for LEDs (PCF8574) 

6. 16550 UART 

• Memory mapped UART with HAV flow control and dedicated interrupt 

• Dedicated interfece to modem V.90 on telephony board 

7.. Communication Ports 

All Channels use the CPM capabilities and therefore will be constrained only by the performance 

of the CPM and its Time Division Multiplexing capabilities. 

SCC2 

• IEEE 802.3 compliant (based on MC68 1 60 (Ethernet)) 

• IrDA (2.4K to 4Mb/s) - HAV only 

SMCl 

• 1 - 7816 compliant full size, smart card interface 
SMC2 

• Non-isolated RS232 port 
USB 

• Dedicated keyboard interface - non compliant with USB host standards 
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I2C 



• 8 additional onboard GPlOs (PCF8574) 

• Digital potentiometer - LCD brightness control 

• 16KbEEPR0M 

SPI 

• Touch screen A/D interface 



8. Development and Debng Capabilities 

• MPC823 BDM port (non-isolated) 

• Dedicated Logic analyzer ports for primaiy MPC 823 address, data and control logic 

• Memory mapped debug LED's 4 character, 5x5 ASCII interface 



Logic Block Diagram 



System memory 



tWS^ Memory 




Hfitst bnStfns & nuts 



Video 



CRTOutput 



3J3JSV 



^ i ^ _ i i i i 

EEISH Mil 



5112 
VDC 



^^r*^ Touch Saeen 



Logic board 

proof or port 
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Telephony Board Functionality 

Processor Independent Telephony Solution 
1-line or 2-line operation - user configurable . 

1. Line One Features 

• Full featured handset/handsfree capability 

• Type I and ir Caller ID' features, 

• Full duplex handsfree 

• Shared Voice or modem (1 -line scenario) 

• Isolated PSTN interface 

• Does not include DTAD or Voltage Message Waiting capability 

• Powered only operation i.e., no POTS operation 

2. DSP-based Handsfree and TrueSpeech ^ Audio (Line I only) 

• Integrated Full Duplex Handsfree 

• DTMF/Tone generation and detection 

• Audio streaming de/compression as per DSP Group CT8021 (See table below) 

• Other than basic DSP driver support, functional driver support for listed incremental functions are . 
not supported. 



Supported Speech Coder 


Typical Application 


0.723.1 63 & 5.3 kbps 


H.324 for video conferencing over dial-up V.34 modems 
H.323 multi-media conferencing over LANs and TCP/IP type 
"packet-data" networks (e.g., Internet) 


G.728 16 kbps 


H.320 for video conferencing over ISDN 


TrueSpeech 4.8 & 4.8/4.1 kbps 


Proprietary low bit rate coder 


16-bit or 8-bit linear 
128 or64kbjps 


Microsoft WAVE files 


G.711 Mu-Law/A-Law 
64 kbps 


Standard speech compression used in digital telephony systems 
(e.g.,Tl/Bl) 


Downloadable Speech Coders 




TrueSpeech 8.5 

8.5 kbps 


DSP Group speech coder built into Microsoft Windows 95. 
Also used in some DSVD modems and Internet Telephones 


G.729A+B 
8 kbps 


Optional speech coder used in H.323 


.G.722 
64Kbps 


7 KHz Wide bandwidth ADPCM audio coder used in H.320 
aSDN) ' 



3. Line Two Features 

• Dedicated V.90 Modem interface (2-line scenario) 

• Isolated PSTN interface 

• Type 1- Caller ID 
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Telephony Block Diagram 



Block Diagram V1.3 



TelUnoi T 



AudeSi Confidential - Not for external (Sstribution 




Logic Board t/F 
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We claim: 

1 . A method of providing a.multiple smart card simulator comprising: 

(i) storing a first set of characteristics of a first smart card; 

(ii) creating a first smart card simulator simulating operation of said 
first smart card; 

(iii) storing a second set of characteristics of a second smart card; 

(iv) simulating operation of said second smart card thereby creating a 
second smart card simulator; 

(v) receiving a first input fi-om a first smart card application; 

(vi) modifying said first iiq)ut based on said first set of characteristics; 

(vii) sending a first modified input to said first smart card simulator; 

(viii) modifying said first input based on such second set of 
characteristics to form a second modified input; and sending the 
second modified input to said second smart card simulator; 

SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 PCT/CAOO/00703 

-42- 

(ix) receiving a first output firom said first smart card simulator 
generated in response to said first modified input; 

(x) modifying said first output based on said first set of characteristics 
to form a first modified output; 

(xi) transmitting said first modified output to* said smart card 
application; 

(xii) receiving a second output firom said second smart card simulator 
in response to said second modified input; 

(xiii) modifying said second output based on said second set of 
characteristics to fomi a second modified output; and 

(xiv) transmitting said second modified output to said smart card 
application. 

2. The method of claim 1 where said characteristics include one of the smart 
cards memory size, command sequence, error handling routine or quirks. 

3. The method of claim 1 fiirther comprising the steps: 
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(i) receiving a second input from a second smart card application; 

(ii) modifying said second input based on said first set of 
characteristics; 

(iii) sending a third modified input to said first smart card simulator; 

■(iv) receiving a third output from said first smart card simulator in 
response to said third modified input; 

(v) modifying first said third output based on said first set of 
characteristics; 

(vi) transmitting said third modified output to said second smart card 
^phcation. 

4. A method of simulating a multiple smart card environment comprising: 

(i) • detecting a simulated smart card insertion (step 400); 

(ii) . determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 410); 
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(iv) detemuning available applications (step 420); 



(v) downloading to a simulated card aad to a simulated terminal at 
least one smart card application (step 430) and 



(vi) repeating (steps 400 - 430). 
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Step too 1 


oionng iirsi sei oi cnBraciensiics oi iirsi 
smart card. 






Step 105 1 


oiiiiuidUl ly up&ruiion oi iirsi sman caro^ 
creating a first smart card simulator. 






j Step 110 1 


oiuiiiiy outrUiiu ool ui Oi iciroUi6rioiiCo oi 
second smart card. 






Step 115 


oimuiaiing operaiion oi seconu sman caro- 
creating a second smart card simulator. 




i 


I Step 130 i 


neceiving inpui irom sman caro 
application. 






Step 140 


iviuutiyiiiy iiipul iroiii siGp lou Uaseu on 
characteristics of first smart card. 




1 


Step 150 


Sending modified input to first 
smart card simulator. 




i 


Step 155 



Modifying input from step 130 based on 
characteristics of second smart card. 



Figure 1A 
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▼ 


step 160 


Sending modified input to second 
smart card simulator. 




1 

▼ 


Step 170 


Receiving output from first smart card . 
Simulator 




1 
▼ 


Step 180 


Modifying output from first smart card 
simulator witti first set of ctiaracteristics of 
first smart card. 




1 


Step 190 


Transmitting first modified output to smart 
card application. 






Step 200 


Receiving output from second smart card 
simulator. 




i 


Step 210 


Modifying output from second smart card 
simulator with second set of characteristics 
of second smart card. 




i 


Step 220 


Transmitting second modified output to 
smart card application. 





Figure 1B 
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Step 300 


Ror*oi\/inn cor^onH inr^iit from oor*rM^rl* 

smart card application. 




1 


Step 310 


ivioaiiying s^cono inpui Dasea on iirsi sgi 
of characteristics. 




1 


Step 320 


Sending third modified input to first smart 
card simuiator. 




1 


Step 330 


Receiving a third output from the first 
smart card simuiator. 






Step 340 


Modifying third output based on first set 
of characteristics. 




1 


Step 350 


Transmitting third modified output to 
second smart card application. 





Figure 2 
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Step 400 


Generating a simulated smart card 
insertion. 




1 


Step 405 


Determining characteristics of the 
inserted card. 




1 


Step 41 0| 


Notifying registered listeners. 




i 


Step 420 


Determining available applications. 






Step 430 


Downloading to a simulated card 
and to at least one simulated terminal 
smart card application. 






Step 440 


Repeating steps 400 to 430 





Figure 3 
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